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1 .0  Overview 


This  docuiiKm  describes  ihc  procedure  used  by  the  feckxjqt  software  to  translate 
an  Express  schema  into  the  SQL  statements  which  generate  a  reiaoonal  database 
schema  for  storing  STEP  data.  The  program  which  loads  a  STEP  physical  file  into 
the  database  is  stepwfjsql  and  is  desenbe  in  a  separate  ckicumcnt  }Nickcrson90j. 
The  program  uses  FED-X,  an  Express  parser,  which  is  documented  in  [Clarit90] 
The  software  has  been  developed  as  part  of  the  National  PDES  Testbed  effort  and 
is  funded  by  the  Computer  Aided  Logistics  Suppon  (CALS)  project. 

Three  types  of  issues  arc  involved  in  translating  Express  into  a  relaiionaJ  database 
schema:  translation  of  the  semantic  constructs  of  Express  into  the  data  definition 
language  of  SQL,  resolution  of  limidation  imposed  by  the  database  management 
system,  and  development  of  a  data  dictionary.  The  first  two  are  discussed  in  sccuon 
2.  First,  the  constructs  of  the  Express  language  are  translated  into  relational  con¬ 
cepts.  The  application  of  this  mapping  to  a  particular  Express  schema,  generates 
the  SQL  data  definition  language  which  is  the  basis  for  the  daubasc. 

Secondly  issues  involving  the  particular  database  management  system  (DBMS)  are 
resolved.  In  this  ease  Oracle’s  SQL*Plus  is  being  used,  but  the  translation  also  con¬ 
forms  to  the  SQL  standard  specification  as  desenbed  in  (ANSI86]  unless  otherw  ise 
noted.  The  basic  data  types  defined  in  Express  are  mapped  into  the  data  types  of 
the  SQL*Plus.  The  names  used  by  the  Express  schema  need  to  be  modified  to  be 
acceptable  to  the  DBMS.  For  example,  they  could  be  too  long  or  the  same  as  key 
words  in  the  SQL^Plus. 

Section  3  discusses  the  data  dictionary.  The  n'ciionary  holds  infom.anon  from  the 
conceptual  specification  which  is  not  explicitly  captured  in  the  SQL  schema.  The 
dictionary  captures  some  of  the  constraints  specified  in  the  conceptual  schema 
which  are  not  directly  mapped  into  the  database  management  system's  facilities. 
For  instance,  the  Uniqueness  Rule  as  defined  by  the  Express  language  can  often  be 
handled  directly  by  the  database  management  system;  however,  constraints  such  as 
the  minimum  or  maximum  number  of  elements  in  a  set  are  not  handled  by  most  da¬ 
tabase  management  systems. 

The  dictionary  captures  descriptive  information  provided  by  the  conceptual  schema 
which  is  also  not  directly  represented  in  the  SQL  definitions.  For  example.  Express 
schemas  contain  type  definitions.  Through  these  definitions  semantic  information 
describing  attributes  is  relayed.  For  instance,  the  data  type  “wcightJn_pounds"  can 
be  defined  in  an  Express  schema;  a  user  is  then  able  to  associate  more  meaning  with 
an  attribute  described  as  having  this  data  type,  than  if  the  type  “real"  had  biren  as¬ 
signed  to  that  attribute.  However,  SQL  has  no  expression  available  which  would 
allow  one  to  store  the  depth  of  this  meaning.  Therefore,  the  information  is  stored 
in  a  dictionary. 

Section  4  describes  how  to  run  the  program  fedex  sql  and  how  to  use  its  output. 
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2.0  Mapping  Express  Constructs  into 
Relational  Database  Tables 

This  section  describes  how  the  Express  entity  definitions  are  represented  m  reia- 
tional  tables.  The  translation  of  the  enddes  is  summanzed  as  follows;  «,  1 )  Even 
entity  defined  in  the  Express  schema  is  translated  into  a  table  or  view  m  the  rela¬ 
tional  database.  (2)  An  entity  without  subtypes  is  represented  as  a  table  iit  An 
entity  which  has  subtypes  is  represented  as  a  view  of  the  tadsles  which  represent  us 
subtypes.  Data  can  be  retrieved  from  these  views,  but  not  insened  into  them  t4 1  }f 
an  entity  has  a  “XOR  NULL"  specified  in  the  Express  "Supenype  of  statement,  tt 
has  both  a  table  and  a  view  associated  with  it.  Data  inserted  into  the  table  associ¬ 
ated  with  the  instances  of  the  NULL  subtyix;  enuty  appean  in  the  view  along  wnh 
the  data  from  the  other  subtypes’  tables. 

The  attributes  of  an  entity  arc  represented  either  as  columns  in  the  entity’s  table  or 
as  another  table.  Aggregate  attributes  are  represented  as  separate  ublcs.  The  dic- 
donary  table  EXPRESS YSSATTRIBLTEDESC  indicates  how  the  attribute  is  rep¬ 
resented. 

2.1  Entity  Tables 

A  primary  table,  called  an  entity  table,  is  associated  with  each  entity  with  no  sub- 
types  and  with  each  entity  which  has  'NULL'  as  one  of  its  subtypes.  The  following 
template  shows  the  structure  of  the  endty  tables.  It  is  described  in  the  sections 
which  follow. 


Table  Name  ■  Entity’s  abbreviated  Name 


ID 

SHARABLE 

INHERITED 

ATTRIBUTE 

COLUMNS 

EXPLICIT 

ATTRIBUTE 

COLUMNS 

- - - 

! 

i 

5 

1 

_ 

This  mapping  is  based  on  the  mapping  used  by  the  STEP  physical  file  representa¬ 
tion  of  an  Express  schema  [AUcmuellcrSS].  Specifically,  the  decision  to  represent 
only  entities  with  no  subtypes  in  tables  is  based  primarily  on  the  fact  that  these  are 
the  only  entities  which  can  be  populated  in  a  physical  file.  Furthermore,  the  order 
of  the  columns  is  based  on  the  ordering  of  attributes  in  the  physical  fik  and  the  in- 
hcritancc  rules  for  attributes  are  applied  in  the  same  way.  TTic  use  of  'AND'  and 
’OR’  in  the  supertype  declarations  is  also  unaccounted  for  just  as  in  the  current 
STEP  physical  file  mapping. 
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2.1.1  Table  Name 

The  cable  representing  an  entity  is  named  after  the  entity.  When  the  entity’s  name 
is  too  long,  it  is  abbreviated.  This  mapping  of  the  entity  names  and  table  names  is 
found  in  the  EXPRESS  YS$N AMES  table  and  also  in  a  file  generated  by  the 
fedexjql  program.  The  name  of  this  file  is  TASLE_NAflES  ,  txt:  by  default.  The 
algorithm  for  generating  the  new  names  is  given  below. 

1.  If  the  name  is  one  of  the  key  words  reserved  by  the  DBMS,  the  last  character 
is  changed  to 

2.  If  name  is  less  than  20  characters,  no  abbreviation  is  needed. 

3.  Otherwise,  the  last  vowel  or  repeated  character  is  removed  from  the  name  until 
the  name  is  less  than  20  characters  or  all  these  characters  have  been  removed. 

4.  If  the  name  is  still  not  less  than  20  characters,  the  last  character  of  the  longest 
subword  is  dropped  until  the  shortened  name  is  less  than  20  characters.  A  sub¬ 
word  is  a  portion  of  the  word  which  is  separated  by  underscores  or  pound  signs. 

5.  If  the  name  is  still  not  less  than  20  characters,  the  character  is  used  as  the 
name  abbreviation.  (Thus  a  numeric  name  is  generated  for  the  table  m  the  fol¬ 
lowing  step.) 

6.  Append  a  unique  three  digit  number  on  the  end  of  the  abbreviation  to  guarantee 
that  the  name  is  unique. 

2.1 .1 .1  Tabio  name  for  a  NULL  aubtypa 

The  name  of  the  table  representing  an  entity  with  NULL  as  one  of  its  subtypes  is 
formed  as  follows:  ( 1)  The  entity  is  abbreviated  as  described  above,  (2)  The  string 
“_NULL”  is  appended  to  the  end  of  the  abbreviated  entity  name.  This  table  is  in¬ 
cluded  in  the  view  of  that  entity,  which  is  described  in  section  2.3. 

2. 1 .2  EntIty-ID  Column 

The  first  column  of  every  entity  table  is  ID,  It  contains  a  unique  identifier  for  every 
instance  of  an  entity.  This  identifier  is  used  as  the  primary  key  of  the  entity  tabic; 
and  it  is  likely  to  be  referenced  in  two  situations  outside  of  this  table.  An  entity 
referenced  by  another  entity  as  an  attribute  is  represented  by  this  identifier  in  that 
attribute’s  column  of  the  entity  table.  The  EXPRESSYSSFRNKEYREFERENCES 
table  can  be  used  to  find  out  which  tables  reference  other  tables  or,  conversely,  to 
find  out  where  a  table  is  referenced.  For  an  entity  with  agp^egatc  attributes 
(attributes  whose  type  is  array,  bag,  list  or  set),  the  same  entity  identifier  is  also  used 
in  the  tables  which  contain  the  data  for  these  attributes.  Detail  about  aggregate 
attribute  tables  is  given  below  in  section  2.2.2. 

The  identifiers  generated  from  the  program  stepwf  sql,  which  loads  data  into  the  ta¬ 
bles,  lake  the  following  form: 

tabf9_nam6\00000000 

Table jume  is  the  name  of  the  entity  table,  and  oooooooo  is  a  unique  integer. 
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2.1.3  Sharable  Coiumn 

Every  entity  table  contains  a  column  called  SHARABLE.  This  column  is  currently 
used  as  an  indicator  of  whether  or  not  the  entity  instance  can  be  used  by  more  than 
one  other  entity  instance.  This  is  currently  interpreted  to  mean  whether  the  instance 
is  embedded  in  another  instance  in  the  input  STEP  physical  file. 

In  future  versions  of  the  database  this  could  be  used  in  checking  uniqueness  and 
equality  of  entity  instances.  For  example,  the  question  of  whether  two  points  w  ith 
the  same  coordinates  are  the  same  point  or  two  distinct  instances  of  a  point  is  un¬ 
clear.  If  the  SHARABLE  column  is  FALSE,  the  points  arc  definitively  not  the 
same;  however,  if  the  column  is  TRL^,  the  two  points  may  be  considered  the  same. 
Furthermore,  the  field  could  be  used  as  a  reference  counter  to  asccnain  whether  a 
shared  instance  is  to  be  deleted  when  a  referencing  instance  is  deleted. 

2.1 .4  Inherited  Attributes 

The  next  group  of  columns  to  appear  in  an  entity’s  table  represent  the  non-aggregate 
attributts  inherited  from  the  entity’s  supenype(s).  The  columns  arc  specified  in  the 
order  of  inheritance  defined  by  the  STIEP  physical  file  structure.  The  origin  of  the 
attribute,  the  name  of  the  entity  in  which  the  attnbuie  is  specified  in  the  Express 
schema,  is  found  in  the  EXPRESSYSSSRC  tabic. 

2.1 .5  Explicit  Entity  Attributes 

Finally  the  non-aggregate  attributes  declared  directly  in  the  Express  definition  of 
the  entity  arc  columns  the  table. 

In  the  example  that  follows  the  portion  of  the  Express  schema  shown  produces  the 
SQL  statement  to  create  a  table. 

EXPRESS: 

ENTITY  geometry  (*  GEOM-1  *) 

SUPERTYPE  OF  (point  XOR 
vector  XOR 
curve  XOR 
surface  XOR 
coordinat0_system  XOR 
transformation  XOR 
axis _placement); 

local_coordinate_system :  OPTIONAL  coordinate_system; 
axis  :  OPTIONAL  transformation; 

ENO.ENTITY; 

ENTITY  vector  {*  GEOM-3  *) 

SUPERTYPE  OF  (direction  XOR 
vector_wiih_magnitude) 

SUBTYPE  OF  Tgeometry); 

END_ENTITY; 

ENTITY  direction  (’  GEOM-1 4  *) 

SUBTYPE  OF  (vector); 

X  :  REAL: 
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y  ;  REAL: 

z  :  OPTIONAL  REAL; 
END  ENTITY; 


SQL: 


CREATE  TABLE  DIRECTION  ( 

ID  CHAR(40)  PRIMARY  KEY, 

SHARABLE  INTEGER  NOT  NULL. 

LOCAL_COORDtNATE_SYSTEM  CHAR(40)  T  FOREIGN  KEY 
AXIS  CHAR(40)/*  FOREIGN  KEY  */, 

X  float  not  null, 

Y  FLOAT  NOT  NULL. 

Z  FLOAT 

); 

TABLE: 

DIRECTION 


SYSTEM  ATTRIBUTES 

INHERITED  ATTRIBUTES 

EXPLICIT  ATTRIBUTES  | 

ID 

SHARABLE 

locaLcoordinate 

_system 

axis 

X 

y 

z 

2.2  Attributes 

The  attributes  of  an  entity  are  represented  as  either  a  column  in  the  entity  table  or 
as  a  table  of  their  own.  If  the  attribute  is  aggregate  (an  array,  bag,  list,  or  set),  it 
has  its  own  table;  otherwise,  the  attribute  is  represented  as  a  column. 

The  EXPRESSYSSDEFINEDTYPES  dictionary  table  describes  the  attributes  of 
the  entity  tables.  It  includes  a  short  name  for  the  attribute  and  information  about  the 
type  of  the  attribute  as  it  is  given  in  the  Express  schema.  The  short  name  is  used  in 
assigning  a  name  for  the  attribute  in  the  database.  The  column  EXPRESS.TYPE 
contains  a  code  which  can  be  used  to  determine  whether  the  attribute  is  represented 
as  a  column  in  the  entity  table  or  as  an  aggregate  table.  The  valid  values  for  this 
field  are  AGGREGATE,  ENTITY,  SELECT,  ENUMERATION,  INTEGER, 
REAL,  BOOLEAN,  LOGICAL,  STRING,  and  NTFMBER. 

When  the  type  is  AGGREGATE  or  ENTITY,  the  value  of  the  attribute  is  represent¬ 
ed  in  another  table.  In  the  case  of  ENTITY  the  owning  entity  table  has  a  column 
for  the  attribute.  The  column  contains  a  key  (an  entity  identifier)  into  an  entity  ta¬ 
ble.  In  the  case  of  the  type  AGGREGATE  the  owning  entity  table  does  not  contain 
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a  column  for  this  attribute.  The  entity  identifier  from  the  owning  entity  table  is  used 
to  identify  the  aggregate  data  items  in  the  aggregate  table  as  belonging  to  that  entity. 

2.2.1  Attribute  Columns 

Non-aggregate  attributes  are  reptesented  as  columns  in  the  entity  tables.  The  col¬ 
umns  have  the  same  name  as  the  attribute  when  this  name  is  less  than  30  characters 
(the  maximum  length  allowed  by  SQL);  otherwise,  the  name  is  abbreviated  by  trun¬ 
cating  the  attribute  name  to  27  characters  and  appending  a  unique  2  digit  integer  to 
the  end.  The  same  abbreviated  name  is  used  for  attributes  with  the  same  name  in 
different  tables. 

2.2.1 .1  Datatypes 

Oracle  data  types  are  assigned  to  the  Express  base  types  as  follows  for  the  purpose 
of  representing  attributes  as  columns  in  the  database.  The  table  shows  all  the  base 
types  of  Express  as  described  in  [Schcnck901.  Note  that  the  default  length  of  an  at¬ 
tribute  with  type  string  is  240. 


EXPRESS 

ORACLE 

Integer 

INTEGER 

Integerfn) 

NUMBER(n) 

Real 

DECIMAL 

Real(n) 

NTJMBER(n) 

Number 

NUMBER 

String 

CHAR(240) 

String(n) 

CHAR(n)  for  n  <=  240,  LONG  for  sumgs  up  to  64  K 

Boolean 

INTEGER 

Logical 

IN’~EGER 

The  last  two  base  types  above,  boolean  and  logical,  are  treated  as  special  cases  of 
enumerated  types  which  are  described  below. 

Attributes  with  the  following  complex  Express  types  arc  also  represented  as  col¬ 
umns  in  the  database.  Below  is  a  mapping  of  these  Express  types  to  Oracle  data 
types. 

Entity  CHAR(40)  FOREIGN  KEY 

Select  CHAR(40) 

Enumeration  INTEGER 

E.nymsi4.agn,.ttBS 

Both  enumeration  and  select  types  imply  the  specification  of  a  domain  for 
attributes.  An  enumerated  type  specifies  the  possible  values  for  the  domain 
explicitly;  a  select  type  specifies  the  possible  values  indirectly.  The  values  of  an 
enumeration  are  sto^  in  the  dictionary  table  EXPRESSYSSENUMERATION. 
This  table  assigns  integer  values  to  the  values  of  an  enumeration.  The  integer 
values  are  what  is  then  stored  in  the  attribute  columns.  The  dictionary  table  is 
consulted  to  see  what  the  integer  values  represent.  The  reason  for  storing  the 
integer  values,  rather  than  the  string  values  that  they  represent,  is  the  fact  that  an 
enumeration  type  implies  an  ordering  on  its  possible  values.  In  order  to  enforce  the 
ordering  the  integer  values  are  used. 
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TYPE 

b_spline_CurveJorm  =  ENUMERATION  OF 

(line_segment. 

circular_afc, 

eliiptic_arc, 

parabolic_afC, 

hypert)Olic_arc); 

END_TYPE; 

After  this  type  is  entered  into  the  EXPRESSYSSENUMERATION  table, 
the  table  looks  as  follows: 


TYPE  NAME 


OHOERJO  VALUE 


B_SPUNE_CURVE_FORM  0 
B_SPLINE_CURVE_FORM  1 
B  SPL1NE_CURVE_F0RM  2 
B_SPL1NE_CURVE_F0RM  3 
B_SPL1NE  CURVE_FORM  4 


LINE_SEGMENT 
C1RCULAR_ARC 
ELL)PTIC_ARC 
PARABOLIC_ARC 
HYPERBOLIC  ARC 


Select  type 

With  a  select  type  the  possible  values  of  an  attribute  come  from  the  group  of  the 
possible  values  of  several  other  types.  When  these  types  are  entities,  the  values  arc 
entity  identifiers,  as  if  the  attribute’s  type  had  been  an  entity.  From  the  entity  iden¬ 
tifiers  generated  by  the  database  loader  it  is  possible  to  tell  which  table  contains  the 
entity  instance  information  for  a  given  entry.  The  first  pan  of  the  entity  identifier 
is  the  name  of  the  entity  table. 

On  the  other  hand,  when  the  types  arc  not  entities,  then  the  values  must  be  of  the 
same  base  type  as  these  defined  types.  In  Express  it  is  possible  to  create  an  object 
which  does  not  have  a  single  base  type  through  the  use  of  a  select  type,  fedexjq I, 
which  implements  this  design,  does  not  deal  with  this  situation.  We  assume  that  in 
the  majority  of  instances  of  select  types  the  selection  is  amongst  entity  types;  there¬ 
fore,  a  select  type  attribute  maps  to  the  SQL  type  CHAR(40)  just  as  do  entity  type 
attributes.  When  the  values  of  the  selection  are  not  entity  identifiers,  the  field  rep¬ 
resenting  these  type  attributes  is  still  confined  to  CHAR(40).  The  choices  of  the  se¬ 
lection  for  a  select  type  are  stored  in  the  dictionary  table  EXPRESSYSSSELECT. 

2.2.1 .2  Optional  attributes 

Each  attribute  column  in  the  entity  tables  is  specified  to  be  NOT  NULL  unless  the 
key  word  OPTIONAL  is  specified  for  that  attribute  in  the  Express  definitions.  The 
DBMS  then  only  allows  rows  which  contain  values  for  all  non-optional  attributes 
to  be  inserted  in  the  database. 

2.2.1 .3  Unique  attributes 

When  an  attribute  is  characterized  as  being  unique  in  the  Express  definition,  a 
unique  index  is  created  on  the  column  which  represents  that  attribute  in  the  entity 
table.  The  indices  are  named  after  the  table  to  which  they  apply.  An  integer  is  ap¬ 
pended  to  the  end  of  the  table  name  to  create  a  unique  name  for  the  index.  Every 
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2.2.2 


2.2,2.1 


2.2.2.2 


2.2.2.3 


2.2.2.4 


tabic  has  at  least  one  index  on  the  tD  column.  Ln  this  way  the  Express  uniqueness 
construct  is  directly  supponed  by  the  DBMS  for  non-aggregate  attributes. 

Attribute  tables 

Attributes  with  aggregate  data  types  are  represented  as  tables,  called aesregaie  ta¬ 
bles.  in  the  database.  The  valid  Express  aggregate  data  types  for  attnbutes  are  ar¬ 
ray,  bag,  list,  and  set.  Each  item  of  the  aggregate  object  is  represented  by  a  row  m 
the  aggregate  table. 

Table  Name 

Aggregate  tables’  names  are  created  by  combining  the  abbreviated  name  of  the 
owning  entity  (which  is  the  name  of  the  entity  table)  with  the  name  of  the  attribute, 
which  it  represents.  The  two  names  arc  separated  by  a  pound  sign  (#),  and  then  the 
new  string  is  abbreviated  using  the  same  algorithm  described  above  for  naming  en¬ 
tity  tables.  The  unabbreviated  and  abbreviated  string  pair  are  entered  into  the  dic¬ 
tionary  table  EXPRESSYSSNAMES. 

ID  Column 

The  first  column  in  every  aggregate  table  is  called  ID.  The  values  in  this  column 
correspond  to  the  values  in  the  ID  column  of  the  owning  entity’s  table.  Whereas, 
in  the  entity  table  there  is  only  one  entry  for  each  unique  entity  identifier,  in  this  ta¬ 
ble  there  are  multiple  rows  for  a  given  entity  identifier.  The  value  of  the  ED  column 
is  the  same  for  all  the  items  contained  in  a  a  single  aggregate  attribute. 

Value  Column 

The  last  column  in  all  aggregate  tables  is  called  VALUE.  This  column  contains  the 
data  for  the  individual  data  items  of  the  aggregate  object.  For  example,  if  the  ag¬ 
gregate  is  a  “list  of  integer”,  this  column  contains  integers;  if  the  aggregate  is  a  “set 
of  cartesian  points”,  this  column  contains  entity  identifiers  from  the  cartesian  point 
entity  table. 

Aggregate  Positioning  Columns 

The  second  column  in  an  aggregate  table  indicates  the  position  of  the  individual 
data  item  in  the  aggregate  object.  The  name  of  this  column  is  determined  by  the 
type  of  the  aggregate  object.  For  example,  if  the  object  is  an  array,  this  column  is 
cadled  SUBSCRIPT_1.  The  column  name  can  be  determined  from  the  following  ta¬ 
ble: 

AGGREGATE  TYPE  COLUMN  NAME 

Array  SUBSCRlPT_n 

Bag  ELEMENT_ID_rt 

List  POSmON_[D_n 

Set  ELEMENT_ID_rt 

The  n  in  the  column  name  is  an  integer,  \  rich  is  always  1  for  a  simple,  not  nested, 
aggregate  attribute. 

When  the  aggregate  is  a  list,  the  following  column  is  PREVIOUS_ID_n. 
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2.2.2.5  Nested  Aggregate  Objects 

If  the  aggregate  attribute  is  nested,  or  multi-dimensional,  more  positioning  columns 
follow  the  initial  one.  These  columns  arc  named  in  the  same  way  as  the  initial  po¬ 
sitioning  column,  as  described  above.  The  integer  n  in  the  column  name  indicates 
the  nesting  level  that  this  column  represents.  For  example,  for  a  two-dimensional 
array  there  are  two  positioning  columns  SUBSCRIPT_1  and  SUBSCRIPT_2.  The 
first  column  contains  the  value  of  the  first  subscript  of  the  array  and  the  second  col¬ 
umn  contains  the  values  for  the  second  subscript  of  the  array.  The  data  for  the  item 
at  position  [1,2]  of  the  array  would  have  a  row  in  the  table  which  contains  the  fol¬ 
lowing  entry: 

ID  SUBSCRIPTJ  SUBSCR1PT_2  VALUE 

entity-id  1  2  data  item 

2.2.2.6  Optional  and  Uniqueness  Concepts 

The  Express  concepts,  optional  and  unique,  are  not  directly  supportable  for 
aggregate  attributes  by  a  relational  database  system  under  this  mapping.  The 
information  is  stored  in  the  dictionary  tables  EXPRESSYSSARRAY, 
EXPRESSYS$BAG,  EXPRESS  /S$LIST,  and  EXPRESSYSSSET. 

With  non-aggregate  objects  the  Express  key  word  UNIQUE  is  represented  in  SQL 
by  creating  a  unique  index  on  an  attribute.  However,  the  translation  of  UNIQL'E 
with  complex  objects  involves  comparing  the  objects  element  by  element.  Further¬ 
more,  equality  is  not  defined  for  aggregate  objects;  therefore,  uniqueness  for  nested 
aggregate  objects  is  not  enforceable. 

In  Express  the  key  word  OPTIONAL  within  aggregate  attributes  indicates  that  not 
all  the  data  elements  of  the  attribute  must  be  specified.  This  is  different  than  desig¬ 
nating  that  the  object  is  an  optional  attribute  of  the  entity,  which  is  modeled  by  the 
non-use  of  the  NOT  NULL  clause  in  the  entity  table  definition. 

2.3  Entity  Views 

Entities  which  have  subtypes  are  represented  as  views  of  the  entity  tables  in  the  da¬ 
tabase.  Views  serve  as  tables  for  the  purpose  of  retrieving  data  from  the  database, 
but  data  can  not  be  inserted  in  or  deleted  from  the  views  directly.  Entity  views  are 
named  using  the  algorithm  given  earlier  for  naming  entity  tables.  Also  as  with  en¬ 
tity  tables  the  original  and  abbreviated  name  arc  entered  into  the  EXPRESS Y- 
SSNAMES  table.  TTie  entity  views  contain  an  ED  column  and  columns  for  all  the 
non-aggregate,  explicit  and  inherited  attributes  which  belong  to  the  entity  being 
viewed  There  are  no  views  for  the  aggregate  attributes. 

The  dictionary  table  EXPRESS  YSSCLASSES  shows  the  class  hierarchy  and  can  be 
used  to  see  which  entity  tables  arc  included  in  a  view 
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3.0  Dictionary 

Founcen  dicuonax%'  tables  arc  uvcd  to  sionr  icituxtuc  snJontiasiUR  tound  m  i-Kpress 
schemas.  Identical  tables  arc  established  tor  each  xnd  eser>  scherna  The  SQL 
siatemenis  for  creating  these  tables  are  found  sn  the  beginning  of  the  .'na-n  oatpet 
flic  oi fedex  jql.  The  dictionars  tables  sunmur.acd  below  arc  desented  ct  deta:; 
tn  the  in  the  document  Tramlatujn  of  an  Expresi  .Schemo  inu:>  SQL  In  the  database 
the  names  of  these  tables  arc  pretl.s.cd  by  EXPRESS  YSS  so  indicate  that  ihe>  are 
dictionar\-  tables. 

Four  of  the  tables  involve  the  .handling  of  aggregate  data  tvpes  One  tabic  .'r.al.'■;ta;r:^ 
information  pcruinmg  to  subtspe  and  supenspe  reiacons  Another  table  oorrs  srx 
logical  narmts  of  tables.  Ftnally  there  are  tables  for  representing  the  Hvprcss  typx 
definitions  and  another  for  recording  descriptions  of  entity  aitnbutcs  in  she  terms  ih 
these  definitions. 

3.1  Entity  descriptions 

•  NAMES;  maps  E.sprcss  names  to  the  names  used  by  the  databa.vc  sy  stctti 
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•  CLASSES;  captures  the 

class  structure  of  the  Express  schema 
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3.2  Attribute  descriptions 

The  tables  used  to  desenbe  attnbutes  are  the  following: 

•  ATTRIBUTEDESC;  contains  Express  type  information,  whether  the  attnbute 
is  optional,  unique,  or  sharable,  and  the  name  used  to  represent  the  attribute  in 
the  database  (Sec  the  attached  table.) 
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FRNKEYREFERENCES  snaps  attnbuscs  so  the  lablc  \*hsch  Aouid  represent 
them 
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•  ATTRSRC:  indicates  the  entity  from  which  an  attnbute  originated  m  the  inher¬ 
itance  hierarchy 
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3.2.1  Aggregate  attribute  descriptions 

The  following  tables  apply  to  aggregate  attributes: 

•  ATTRBEXPRESSTYPE:  holds  information  for  reconstructing  type  informa¬ 
tion  for  nested  aggregate  (i.e.  multi-dimensional)  attributes 

•  ARRAY: 


OBJECT_TA8LE 
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SEQUENCE.NUMBER  LOW.BOUND  HIOH_BOUNO  OPTIONAL  UNK3UE_ELEMENTS 
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•  BAG,  LIST,  and  SET  arc  very  similar  to  the  array  tabic  and  arc  described  in  de¬ 
tail  in  [Metz89]. 
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Description  of  defined  types 

The  following  tables  contain  information  about  schema-defined  types; 

•  DEFINEDTVPES:  records  dcfiniuon  of  type  defined  w  uhin  the  Express  sche 
ma 

This  table  contains  two  columns  which  map  a  type  name  to  a  data  type  as  declared 
in  the  TYPE  block  of  the  Express  schema.  The  value  of  the  DEFLMTION  column 
of  this  table  is  cither  the  name  of  an  Express  base  type,  the  name  of  an  aggregate 
type,  the  key  word  “ENUMERATION.”  the  key  word  "SELECT/'  the  key  s«,ord 
“AGGREGATE”,  an  Express  entity  name,  or  the  value  of  the  NAME  column  from 
another  row  in  the  table. 

TYPE  DEFIH1TX3W 

IN?  IN  I  It  N 

iNTiRSiCT :  r :  :s  at  :  in¬ 
set  Or  oz: 
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•  ENUMERATION; 
tion 

records  the  possible  values  of  a  type  which  is  an  enumera 

TYPE_NA»»S 

0RDER_1D 

VALUE 

S'JRr  rOR-W 

I 

SOUSOEO  PLANAR 

sun-  FORM 

I 

aCUSEED  RULE 

SURF  FCR.M 

•> 

4. 

3CUNOEO  COMPLEX 

SURF  FORM 

3 

:N30UN0E0  ?LA.NA.a 

3URF_FCR.M 

A 

■JS3CUNDE0  SOLE 

SURF_F0RM 

Q 

UNBCUNOED  COMPLEX 

SURF_T;fPE 

0 

C lACOLAK 

SURF  TYPE 

I 

FLAT 

SURF_TYPE 

2 

GENERAL 

♦  SELECT:  records  the  types  of  a  selection 

TYPE.NAME 

CHOICE 

SELECT  FACE  OB  SUBFACE 

FACE 

SHAPE_0R  DERIVED 

OT  SHAPE  ASPECT 

SHAPE  OR  DERIVED 

GEOMETRIC  DERIVATtCS 

The  following  table  is  used  by  the  program  stepwfjql  which  loads  a  STEP  file  into 
the  database: 

•  INSTANTIATEDTABLES:  keeps  track  of  which  tables  are  actually  populated. 
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4.0  The  program:  fedex_sql 

The  pTogrdimfedex_sql  is  pan  of  the  NTST/PDES  Fcd-x  toolkit  This  mcxlulc  trans 
lates  an  Express  schema  into  a  relational  database  schema  using  the  meihtxiology 
described  in  this  document.  TTie  Fcd-x  toolkit  is  described  m  detail  in  the  dcx'u- 
ments  [Clark90]. 

4.1  Running  the  program 

Two  steps  are  needed  to  use  the  software  for  translating  an  Express  schema  into  a 
relational  database  schema.  First  the  SQL  statements  for  creating  the  database 
schema  are  generated.  Then  these  statements  arc  loaded  into  the  database.  The  doc¬ 
ument  [Strousc90)  describes  this  process  for  the  NIST/PDES  Testbed  environment. 
To  run  the  program  on  your  own  follow  the  uistniciions  given  here. 

4.1 .1  Generating  the  SQL  schema  definition  statements 

1)  The  command  line  for  fedexjql  is  the  following: 

fedex_sql  -e  express-schema-file 

The  expressschema-file  is  the  file  where  an  Express  schema  is  stored.  The  program 
may  then  print  out  some  warning  messages  regarding  the  schema. 

2)  Next  the  program  prompts  for  the  name  of  an  output  file.  The  SQL  staicments 
to  create  the  database  schema  are  stored  in  this  file,  so  it  should  probably  end  in  the 
•  sql  extension. 

3)  The  program  then  prompts  for  a  file  containing  a  list  of  entity  and  tabic  names. 
The  default  the  file  is  T able_names  .  t  xt .  If  the  file  name  provided  is  not 
found,  no  file  will  be  used  and  the  program  will  generate  unique  abbrevianons  for 
the  entity  names. 

4)  Finally  the  program  prompts  for  the  name  of  a  file  in  which  to  store  the  list  of 
entity  table  names.  If  no  file  name  is  provided,  the  names  are  stored  in  the  file  ta- 
3LE__NAMES.txt  in  the  working  directory. 

4.1.1 .1  Output  files 

When  this  program  is  finished,  six  files  will  have  been  created.  The  names  of  two 
of  these  arc  supplied  by  the  user  in  the  steps  above:  the  names  supplied  when 
prompted  for  an  output  file  (step  2)  and  a  file  for  the  table  names  (step  4),  TABLE_- 
NAMES.txt  by  default.  The  others  are  DICT_DATA.  sql,  DICT_INDI- 
CES .  sql,  SUPERTYPES .  sql,  and  INDICES ,  sql  and  are  found  in  the 
working  directory.  Warning:  if  any  of  these  files  existed  in  the  working  directory 
before  the  program  was  run,  they  would  have  been  replaced  by  the  new  files. 

The  main  output  file  contains  the  statements  for  creating  all  the  tables.  The  begin¬ 
ning  of  this  file  creates  the  dictionary  tables;  the  remainder  creates  the  entity  and 
aggregate  tables. 
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Each  line  of  ihc  file  of  table  names  contains  two  words.  Tltc  first  is  the  abbreviated 
entity  name  to  be  used  in  generating  table  names,  and  the  second  is  the  entits  name 
used  m  the  Express  schema.  The  line  following  the  list  of  names  contains 
*♦*"  which  signifies  the  end  of  the  list.  The  next  and  last  line  contains  an  integer 
which  is  the  first  number  the  program  will  use  in  gcncraung  unique  abbreviations, 
if  they  arc  neetted. 

The  file  D  ICT_DATA .  sql  contains  the  SQL  statements  that  populate  the  Express  • 

data  dictionary.the  other  dictionary  fiicDlCT_:N2:Z£S  .  sql  contains  the  state¬ 
ments  for  generating  indices  on  the  data  dictionary'. 

k 

The  file  SUPERTYPES  .  sql  contains  the  SQL  statements  to  generated  siews  for 
the  supenype  entities  defined  in  the  Express  schema. 

The  file  INDICES  .  sql  contains  SQL  siaicmcnis  to  create  indices  on  the  entity 
and  aggregate  attribute  tables. 

4.1.2  Creating  the  database  tables 

To  load  the  database  schema  do  the  following: 

5)  Log  into  the  database  management  system. 

6)  At  the  SQL>  prompt  type  run  sql-sche:v.a- file,  v,htrc  sql-schema-fde 
the  name  the  user  provided  in  step  3  above.  This  file  takes  some  time  to  load  de¬ 
pending  on  the  size  of  the  schema.  Over  30  minutes  in  the  PDES  Testbed  environ¬ 
ment  is  not  unusual. 

The  process  loads  the  files  DICT_DATA.  sql.  DICT_INDIC£S  .  sql.  and  SV- 
PERTYPES .  sql  automatically  if  they  are  in  the  working  directory. 

At  this  point  the  database  is  ready  to  be  populated.  After  the  database  has  been 
completely  populated,  the  indices  on  the  tables  should  be  created.  This  is  done  by 
typing  run  INDICES  .  sql  at  the  SQL>  prompt. 

4.1 .2.1  Output  files 

The  creation  of  the  tables  generates  a  file  called  error  s  .1st.  This  file  is  a  listing 
of  what  appeared  on  the  screen  during  the  process.  It  should  not  contain  anything 
of  significance,  but  if  there  were  any  problems  the  error  message  will  be  in  this  file. 

4.2  Different  versions  of  the  program 

The  data  definition  produced  by  fedexjql  is  designed  to  work  with  an  Oracle  data¬ 
base.  Due  to  physical  design  considerations  two  tablespaces  arc  used.  In  the  cur-  • 

rent  configuration  these  arc  named  t  s  0  and  t  s  1 .  Entity  tables  are  assigned  to  these 
tablespaces  alternately.  The  indices  for  an  entity  table  and  any  tables  that  represent 
aggregate  attributes  of  that  entity  arc  created  on  the  opposite  tablespace.  * 

An  alternate  version  oi  fedex  jql  is  available  which  docs  not  include  designations 
for  tablespaces.  The  output  of  this  program  is  therefore  easier  to  pon  to  other  rela¬ 
tional  database  systems  which  have  different  configurations.  This  version  is  stored 
as  fedexjtandardsql. 
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hnolhcT  vctsion  of  fedex  jql.  fedex^oracle,  alsocxisis.  This  version  outputs  the 
Express  dictionary  data  m  a  flat  flic  format  rather  than  as  SQL  INSERT  statements. 
One  file  is  created  for  each  dictionary  table,  and  each  file  is  nanwd  for  the  table  that 
it  represents.  A  specialized  tool,  such  as  Oracle’s  SQL'Loader  can  be  used  to  load 
the  dictionary  tables  from  this  output. 
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